The traversal of network address translators (NAT) and firewalls for Mobile IP (internet protocol) focuses only on the communication between the mobile node and the home agent. End points should, however, be able to communicate directly to avoid traffic being routed always through the home agent.
Currently, there are no mechanisms in Mobile IP that allow an end point to determine systematically possible communication paths between two end points and to fall back to reverse tunneling via the home agent only in the worst case.
Stateful packet filtering firewalls behave in a similar way as NATs with the notable difference that they do not change any IP address or port information. Still, they create state based on outbound packets that is later matched against inbound packets. In the following, reference is mainly made to NATs. However, the statements equally apply to stateful packet-filtering firewalls.
Three types of problems occur when NATs and firewalls are located between the mobile node and the correspondent node. Firstly, communication might not be possible along these paths, whereby failures occur without a chance for the end points to determine where the source of the problem is and to have means to fix it. Secondly, there is no systematic way to determine which paths are available and which ones should be selected to exchange data traffic. Finally, data traffic has to travel via the home agent and therefore communication is more costly in terms of latency and cost. An outlook of a few problems is provided in a document by F. Le, et al., “Mobile IPv6 and Firewalls: Problem Statement”, RFC 4487, May 2006, by the Internet Engineering Task Force (IETF).
Some approaches of the prior art to deal with one or more of the above problems are as follows. It is possible to route all traffic via the home agent (reverse tunneling). This option introduces costs and latencies, as previously mentioned. Further, it may be possible to configure firewalls so that they allow all Mobile IP traffic. This is a difficult deployment practice. It does not work for NATs. In addition, the end points could use some kind of “middlebox signaling protocol”, such as disclosed by M. Stiemerling et al.: “NAT/Firewall NSIS Signaling Layer Protocol (NSLP)”, work in progress, IETF Internet-Draft draft-ietf-nsis-nslp-natfw-14, March 2007; UPnP Forum, “Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0”, November 2001; M. Stiemerling, J. Quittek, C. Cadar, “NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0”, RFC 4540, May 2006; and M. Stiemerling, J. Quittek, T. Taylor, “Middlebox Communications (MIDCOM) Protocol Semantics”, RFC 3989, February 2005, to talk to the NAT and firewall to allow subsequent data traffic to bypass. While some of these protocols work only in local networks, such as the approach with internet gateway device, others work with central controllers, such as “MIDCOM” or “SIMCO”, while the NSIS work seems to be the most promising candidate that would technically provide some of the required functionality. However, neither the NSIS work nor MIDCOM/SIMCO enjoys deployment, and there is currently no indication that this deployment will happen any time soon. Finally, a protocol for end-to-end connectivity checks has been defined in the IETF SHIM6 working group, called REAP (J. Arkko, I. van Beijnum, “Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming”, (work in progress), draft-ietf-shim6-failure-detection-07, December 2006). It only works on IPv6 (internet protocol version 6) and it only tests source and destination address pairs, not flows.